Ja, danke schön. Schön, dass Sie hier sind. Ich muss gleich vorweg sagen, ich muss den
Talk auf Englisch machen, weil die Folien sind Englisch und alle meine Notizen sind
Englisch. Wenn ich das auf Deutsch versuche, dann werde ich so, dann wird das so konfus,
dass es für niemanden hier was bringt, wahrscheinlich. Deswegen Englisch. So, Titel
of the talk is SSR, SPAs and PWAs. The subtitle is The Return of Progressive Enhancement,
which is mostly a term of maybe like five to ten years ago, so it was not as important
in the last few years as it was before. My name is Marc Cortevitte. We are all from
of simple apps. We work for international clients, build web apps, both server side and client
side. I'm not going to repeat all that. So, back to the topic. SSR, SPAs, PWAs. So, basically,
the idea of the talk is to look at how those work and how those can work together, which
will also bring us back to the subtitle later on. First of all, though, I want to look at
what these acronyms even mean, because that's obviously the foundation for discussing how
they could work together. And for doing so, we look at an example app. So, we are assuming
an application here that gives access to air quality data, which is obviously an important
topic with upcoming driving bans across Europe. So, let's assume we want to help fix that
air quality situation, raise awareness a bit and give people easy access to air quality
data. So, you might imagine that the start screen for web app that does that might look
something like this. Like you have a search field where you can search for a location
by name. Let's say you search for Erlangen or so. Or most of the time probably you would
be interested in air quality data for your current location, like around you, because
that's the air you're breathing, obviously. So, anyway, though, any way you start the
search, you get to a result list there, which might look something like this. It's just
a list of results with links to kind of the actual detail pages for those locations.
And then the detail page might look like this. It might say, excellent air, very bad air,
and here's why. Because PM so and so is really high or CO2 is low or whatever. So, let's
look at different ways of building an application like that. And first of all, we look at classic
website, the classic SSR server-side rendered website, where the application is, like I
said, fully rendered on the server side. Or maybe it's pre-rendered, maybe it's just
a static HTML file. And that HTML that the server has is then sent to the client. It's
a complete document that the client, the browser receives, and that's maybe enhanced in the
browser with some JavaScript or so. A concrete example is like this. Here we have the server
on the right, and the browser makes the request for that initial document, like get slash,
get the root page of the document. It gets the document from the server. Then you would
enter search term. You would start the search that results in another request to the server
again, which again responds with a pre-rendered or with a server-side rendered document. And
then you select one of these locations, results in another request, and you get another server-side
rendered document for the results of, for the air quality results for that particular
location. The characteristics of the approach are obviously the document is visually complete
as it is received from the server. The document contains everything that's needed, like all
the information and all the logic and all the styling sort of is included in that document,
leaving alone that the styles are probably in an external style sheet, but all of the
application of the classes and so on. That's all in that server-side rendered document.
And also the document immediately function. You can immediately, as you receive the document,
as it gets rendered by the browser, you can immediately fill in the search form and submit
it back to the server-side. And of course, all pages are independent of each other. So
every time you switch to a different page or you submit the form or whatever, you have
like a full request-response cycle and reload the complete page. Just classic way of how
the web works. The first iteration step on that classic approach sort of was single-page
apps, where you essentially ship an empty document to the browser that just has some script tags,
the browser loads the script, boots up the application, and then everything runs in
Presenters
Marco Otte-Witte
Zugänglich über
Offener Zugang
Dauer
00:45:58 Min
Aufnahmedatum
2018-09-13
Hochgeladen am
2018-09-13 17:27:23
Sprache
en-US
Outline:
SSR recap – what is it, how does it work?
* send pre-rendered vs. empty document
* improving perceived performance
* Giving non-JS clients something they can work with (e.g. Twitter Cards etc.)
Typical problems
* jQuery obviously not available
* => problems with SSR mostly caused by bad patterns (e.g. jQuery)
* Relying on `localStorage`/`sessionStorage` => move to cookie
Disabling interaction on the pre-rendered document
* Simple case is to disable complete document => result often not great
* Better:
* selectively disable elements that require app to run
* Render them in a loading state (signals the user “this is still setting up”)
* Some elements are functional without a running app already
* Some things can be moved to CSS
Advanced patterns
* Lazy load in the client, bundle everything in SSR as bundle size does not matter much there (e.g. translations)
* Push data in the sandbox (e.g. translations, model data etc.)
* Render differently in SSR/client (e.g. inline SVG in SSR, use image tag in browser)
* Never require SSR to work (fallback to serving non-SSR on SSR errors)
how does this relate to PWAs
* Works well together:
* App frame is fine but app frame + SSR is better
* This can be combined – render app frame first, then put in SSR once available, while app still loads